In the first part of this series, we explored the fundamentals of Oracle Automatic Storage Management (ASM)—a powerful volume manager and file system integrated with Oracle Database. ASM simplifies storage by abstracting physical disks into disk groups and automating tasks like striping, mirroring, and rebalancing. This automation helps ensure high availability, scalability, and optimal performance for Oracle workloads.
But once ASM is up and running, how do you ensure it stays healthy and efficient? That’s where monitoring and proactive maintenance come into play.
This article outlines the key areas to monitor in Oracle ASM, why they matter, and what SQL or tools to use for visibility and alerts.
Disk Group Usage
Why it matters: Disk groups are the heart of ASM. If they fill up, database writes can fail, and performance may degrade. Although rare in modern and far less limited storage solutions of today, it’s still important to monitor the free space of any diskgroup.
What to monitor:
|
1 2 |
SQL> SELECT name, state, type, total_mb, free_mb, usable_file_mb FROM v$asm_diskgroup; |
Recommendations:
- Set alerts when
usable_file_mbdrops below 15–20% of the total disk group size. In larger storage environments, it often makes sense to calculate thresholds by MB free vs. percentage free. - ASM may report enough free space, but due to mirroring and striping,
usable_file_mbis a more accurate indicator of true usable capacity.
Disk Health and Status
Why it matters: A single failed or degraded disk can compromise redundancy, performance, and rebalance operations. Having a clear understanding of the status and availability of disk groups is essential.
What to check:
|
1 2 |
SQL> SELECT name, path, mount_status, header_status, state FROM v$asm_disk; |
Red flags:
MOUNT_STATUS = CLOSEDorUNKNOWNHEADER_STATUS = FORMER,MISSING, orCANDIDATE(unexpectedly)STATE = OFFLINEorUNKNOWN
Rebalance Operations
Why it matters: ASM automatically rebalances data when disks are added or removed. Frequent or slow rebalances may indicate configuration or I/O bottlenecks. The estimates showing minutes left, as well as the amount of work that’s been completed can assist the DBA in knowing the clear status of a rebalance operation.
What to monitor:
|
1 2 |
SQL> SELECT operation, state, power, actual, sofar, est_work, est_minutes FROM v$asm_operation; |
Tips:
- Track how often rebalances occur.
- Monitor if operations remain in an active or long-running state.
- Use
POWERlevel wisely. Although higher values are available in post 11g limits, higher values mean higher IO and CPU to complete faster.
Redundancy and Mirroring Levels
Why it matters: ASM supports different redundancy levels (EXTERNAL, NORMAL, HIGH). Choosing the wrong one for your workload can risk data availability. Mission critical workloads require higher redundancy levels, where development environments can use lower ones.
What to check:
|
1 2 |
SQL> SELECT name, type, compatibility, database_compatibility FROM v$asm_diskgroup; |
Best practices:
- Match redundancy levels to workload importance:
- HIGH: Mission-critical production systems
- NORMAL: General production or staging
- EXTERNAL: When using hardware RAID
- Automate checks to verify that templates align with the expected configuration.
File Access and I/O Statistics
Why it matters: ASM handles all Oracle files—datafiles, redo logs, control files—and poor I/O can severely impact database performance.
Files Overview:
|
1 2 |
SQL> SELECT file_number, type, incarnation, blocks, block_size FROM v$asm_file; |
I/O Stats:
|
1 2 |
SQL> SELECT name, reads, writes, read_errs, write_errs FROM v$asm_disk; |
Insights:
- Join these views with V$ performance views for comprehensive performance analysis.
- Track error counts and abnormal read/write ratios.
ASM Alert Logs and Trace Files
Why it matters: Not all issues appear in SQL views. ASM writes key warnings and errors to its alert logs. Any DBA will know for detailed information on issues or errors, the alert log is the place to go. For ASM, there is a handy tool to provide filtered views of errors.
How to check logs:
|
1 |
adrci> show alert -p "message_text like '%error%'" |
Look for:
- ORA- errors
- Rebalance messages
- I/O errors
- Disk offline or fail events
Tip: Set up log monitoring tools or scripts to scan for critical messages in real time.
ASM and Cluster Instance Availability (RAC Environments)
Why it matters: In Oracle RAC environments, each node runs an ASM instance. ASM unavailability on any node can affect database operations. As RAC has shared storage, it’s essential to monitor the ASM instance on each RAC node. For RAC, as for each database node, the ASM instance must have a unique name for the shared storage. It’s common to number the ASM instance, (i.e. +ASM1, +ASM2…)
What to monitor:
|
1 |
crsctl stat res -t |
Ensure:
- All ASM instances are online and registered with Oracle Clusterware.
- No unexpected restarts or failovers have occurred.
Compatibility and Feature Settings
Why it matters: ASM compatibility levels control access to advanced features like ASM Cluster File System (ACFS), Flex ASM, and more.
Check settings:
|
1 2 |
SQL> SELECT name, compatibility, database_compatibility FROM v$asm_diskgroup; |
Validate:
- Compatibility levels align with Oracle version and features in use.
- Features like ADVM and Flex ASM are configured only where supported.
Bonus Tips for Proactive Monitoring
- Set up custom scripts to check space usage and disk health daily.
- Leverage Oracle ASMCMD for file-system-like navigation and troubleshooting.
- Monitor ASM patch levels to ensure they are in line with Oracle’s recommendations.
- Track fragmentation and rebalance trends to catch early signs of performance issues.
Conclusion
Oracle ASM automates many storage management tasks, but like any critical infrastructure, it requires careful monitoring to ensure reliability and performance. By keeping a close eye on disk group usage, disk health, I/O metrics, and rebalance activity and setting up proactive alerts, you can prevent issues before they impact your database.
Oracle can have many architecture solutions, no matter if it’s a single instance, multi-tenant or Oracle RAC, best practices will help you unlock the full power of ASM while maintaining the high availability and performance your Oracle environment requires.
Load comments